IBIS Macromodel Task Group Meeting date: 27 February 2018 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: * David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte SPISim: Wei-hsing Huang Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Radek: Motion to approve the minutes. - Mike L.: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: BIRD189: - Arpad: [sharing his 'Referencing Problems' presentation] - Michael M. mentioned at the last Interconnect meeting that we need to put a halt on these discussions and come up with a decision. - I've prepared some slides to illustrate the referencing issues. - [slide 1] - For illustrative purposes, I keep distinct node names for all the terminals, even if they are shorted (à la .connect statement in SPICE). - Simple S-parameter block. Unity gain VCVS with a 1 Ohm resistor for the Thevenin circuit on each side. - All port voltages (difference between port pos and neg terminals) are identical. - This example shows no connection to "ground". So it should satisfy tools with no concept of node 0. - [slide 2] - These examples won't give the correct results in any simulator because there is no complete loop in the connection between S1 and S2. - [slide 3] - These examples both work. It's not required that all the reference nodes be the same. We just need continuity in these loops connecting the blocks. - [slide 4] - Modification of slide 1 - all the reference terminals are shown tied directly to node 0. - Note that any Ohmic connection to node 0 would do (short, 1G Ohm, 1M Ohm). - This provides the DC path to ground most SPICE-like tools want. - Now plotting individual terminal voltages (with respect to node 0). - All reference terminals are 0 (node 0). - All positive terminals show the identical waveform (same waveform seen in the port voltage plots in slide 1). - [slide 5] - Same circuit, except that each block's common reference is now tied to a different node with a different DC offset (relative to node 0). - Common references for each block, but because each block's reference is different the port voltages for ports 3 and 4 are not the same as ports 1 and 2. - The different DC references for the blocks cause incorrect results. - [David Banas noted that the AC waveforms on the positive terminals were unchanged. Arpad agreed.] - [slide 6] - Like slide 5, but add "noise" to the DC sources connected to the reference terminals. - We might have an IBIS Tx on one end of a ground plane and an IBIS Rx on the other end. The ground plane will have noise unless it's ideal. - Noise effects couple into the port3 and 4 voltage waveforms. - This is why I firmly believe that if we allow different references to be used for the different blocks in an interconnect model we could get incorrect results. - [slide 7] - Proposed solution 1 for IBIS. - Require all reference nodes to be tied together (but not necessarily to node 0). - Even with the non-ideal noisy reference the output port voltages are as expected. - This is the simplest solution in terms of minimizing changes to our current BIRDs. - [slide 8] - This is the more general N+2 approach. - Just make sure we have the same reference for the connected terminals of adjacent blocks. - In this example each of the three references has a different "noise" source, but the final port voltages are still correct. - This would be significantly more work in terms of updating the BIRDs. - Going from N+1 to N+2 would involve lots of changes. - For expediency's sake, I think it's okay go with the approach (slide 7) that the reference for all ports is the same node. - Discussion: David Banas asked if the N+2 approach would cause compatibility problems for tools, for example because SPICE typically supports N, N+1 or 2N terminal approaches. Arpad noted that N+2 is a subset of the 2N approach, with half of the reference terminals tied to one node and the other half tied to a second node. Walter noted that the example in slide 8 (N+2) could be handled by wrapping it in a subcircuit instead of using the Touchstone shortcut in BIRD189. He also noted that adopting the N+2 syntax would mean adding more syntax to define which were the "left" and "right" ports. Arpad agreed that this was part of the significant effort that adopting N+2 would entail. Walter recommended that we stay with N+1, and that we make it a rule or a note that the same node should be the reference for all blocks. Arpad noted that keeping the N+1 approach without mandating that all of the N+1st terminals were connected to a common node would leave us open to the bad results seen in slide 6. Arpad preferred that we clean up BIRD189 to say that all Touchstone devices' reference terminals were tied to the same node. Radek reiterated that N+2 offered no real advantages. He also reiterated his preference for using the A_gnd in BIRD189 as the way to specify the common reference node, instead of its current use in specifying node 0 as the reference for particular blocks. Arpad agreed that we could adapt A_gnd to serve as the common reference for all Touchstone shortcut blocks. Radek noted that in slide 2 the simulator would probably give you the "right" answer, but it gives you the answer based on the way the connections and circuit configuration are specified. However, we have to remember that one important aspect of the simulation may or may not be correct with respect to what's inside the S-parameter block. When the model maker creates a 2 port model with 4 terminals (2N), that's a specific decision that is made to do it that way (as opposed to the N+1 approach). He noted that he'd discussed the issues with that extra degree of freedom before. The simulator is likely to address this extra degree of freedom by enforcing that the currents entering and leaving port 1 must be equal, and the currents entering and leaving port 2 must be equal. You get a solution based on this condition. Whether this is true for the actual circuitry inside the S-parameter block is a separate issue we have to be aware of. Radek noted that he hoped to prepare some language on how the external circuitry may interact with the way N-port devices are treated internally. He hoped to have this language ready for the Friday Interconnect meeting. Bob asked if Arpad had indeed meant 2-port devices for all the blocks. Arpad confirmed that he had, and noted that he had shown 4 terminals in all the examples for consistency. For the N+2 examples they are required, but for the typical N+1 examples he had shown the two reference terminals tied together externally. To clarify things based on this discussion, Arpad redrew the examples on the right hand side of slides 2 and 3 to show the two ports' reference terminals tied together within the block and only 3 terminals emerging from the block (N+1 scenario). [this appears in the posted version] Radek noted that slide 5 relates to the issue he discussed with BIRD158 in the context of BIRD189. We have this issue with a BIRD189 model that may contain the rails as well as the I/O, but the BIRD158 model only addresses the I/O. Radek noted that we might address this by extending the A_gnd idea to the BIRD158 models so the rail could provide the reference for BIRD158 models. Radek noted that Arpad's observations in these slides was consistent with what he wanted to propose. Walter noted that only DC offsets were introduced in the slide 5 example. He noted that the AC levels were not altered in this example. Based on this, he suggested that the only requirement for BIRD158 might be that each reference terminal is connected to a constant level voltage source. Since BIRD158 is for AMI, and AMI uses an impulse response to characterize the channel, any DC shifts in the final port voltage waveform don't matter. Arpad noted one other thought experiment he had done. Instead of connecting all the reference terminals together, what if the "channel model" in the middle of the simulation were the lone N+2 model? Then, all the blocks on the Tx side of the channel could be connected to one reference, and all the blocks on the Rx side of the channel could be connected to another reference. As long as the channel model block were N+2, it would be like having an isolation transformer in the middle. - Mike L.: Motion to adjourn. - Michael M.: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 06 March 2018 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives